Cómo conseguir Quorum en Proxmox usando Corosync desde un Docker en un NAS

¿Qué es el Quorum y por qué es tan importante en Proxmox?

Cuando montas un clúster Proxmox pequeño, tarde o temprano te topas con el mismo problema, el quorum. Con dos nodos cualquier reinicio, mantenimiento o corte de red te deja el clúster a medio gas o directamente bloqueado. Y claro, añadir otro servidor físico solo para eso no siempre es una opción.

Aquí es donde entra en juego una solución bastante "apañada", usar la infraestructura Docker que corre en un NAS (Asustor, Synology, QNAP...) como QDevice del clúster, ejecutando Corosync (sistema de código abierto para la gestión del quorum en clústeres) dentro de un contenedor Docker y conectándolo a los nodos Proxmox por la misma red local.

No es una configuración pensada para producción crítica, pero para laboratorio, pruebas de alta disponibilidad y entornos domésticos o de formación funciona sorprendentemente bien. Además, aprovechas hardware que ya tienes encendido 24/7 y evitas gastarte dinero en más máquinas.

En esta entrada explicaremos cómo montar este escenario paso a paso, qué detalles son importantes para que Corosync funcione sin dolores de cabeza y por qué usar UDP Unicast en lugar de multicast es clave cuando mezclamos Proxmox, Docker y un NAS.

¿Qué es el Quorum en Proxmox?

En un clúster, el quorum es el mecanismo que decide si el conjunto de nodos está en un estado válido para seguir funcionando. Su objetivo principal es evitar situaciones peligrosas como el split brain, donde varias partes del clúster creen tener el control al mismo tiempo.

Corosync, que es la base del clúster en Proxmox, funciona con una regla muy simple:

• El clúster necesita más de la mitad de los votos para estar operativo.
• Si no hay quorum, Proxmox bloquea acciones críticas como arrancar máquinas virtuales, migrarlas o modificar el estado del clúster.

Algunos ejemplos rápidos:

• Clúster de 2 nodos: Si cae uno, no hay quorum.
• Clúster de 3 nodos: Puede caer uno y el clúster sigue funcionando.
• Clúster de 4 nodos: Mucho más tolerante a reinicios y mantenimientos.

Por eso es habitual añadir un nodo extra solo para quorum. Y aquí es donde un NAS con Docker puede encajar perfectamente.

Proxmox + Corosync en Docker dentro de un NAS

El escenario que vamos a montar es el siguiente:

• Dos nodos Proxmox reales (aunque la imagen veáis 3)
• Un NAS Asustor ejecutando Docker
• Un contenedor Docker con Corosync que actúa como nodo adicional
• Todos los equipos en la misma red LAN (192.168.2.x)
• Comunicación mediante UDPU, evitando multicast

Como ya he comentado anteriormente, no es una configuración pensada para producción, pero para laboratorio, pruebas de alta disponibilidad y técnicos que no pueden permitirse un tercer nodo para casa.

¿Por qué usar UDPU (UDP Unicast)?

• No depende de multicast
• Funciona mejor en redes mixtas (Proxmox + NAS + Docker)
• Es más estable en entornos domésticos
• Totalmente compatible con Proxmox

Arquitectura y Requisitos del Clúster

Arquitectura del Clúster

La topología del clúster queda así:

Nodo	Plataforma	IP
proxmox1	Proxmox VE	192.168.2.11
proxmox2	Proxmox VE	192.168.2.12
nas-docker	NAS Asustor (Docker con --net=host)	192.168.2.50

El detalle clave es que el contenedor Docker hereda la IP del NAS gracias al uso de host networking. A efectos de Corosync, ese contenedor se comporta como un nodo más del clúster (sin serlo, sólo nos da un voto adicional para el quorum).

Requisitos previos

En los nodos Proxmox

• IP fija en todos los nodos
• Corosync ya instalado (viene por defecto)
• Todos los nodos en la misma subred

En el NAS Asustor

• Docker instalado (Docker-CE o Portainer desde App Central)
• IP fija configurada en ADM
• Contenedores privilegiados habilitados
• Soporte para --net=host
• Puerto UDP 5403-5405

Recomendación clara: usar UDPU. Multicast suele dar problemas en switches domésticos y en muchos NAS.

Configuración de Corosync

El archivo corosync.conf debe ser idéntico en los dos nodos Proxmox. El fichero tendrá el siguiente contenido:

logging { debug: off to_syslog: yes}nodelist { node { name: minis
 nodeid: 1 quorum_votes: 1 ring0_addr: 192.168.2.11 } node {
 name: minis2 nodeid: 2 quorum_votes: 1 ring0_addr: 192.168.2.12 }}
 quorum { provider: corosync_votequorum device { model: net votes: 1
 net { algorithm: lms host: 192.168.2.50 tls: off } }}
 totem { cluster_name: NEGULAB config_version: 9 interface { linknumber: 0
 } ip_version: ipv4-6 link_mode: passive secauth: on version: 2}

 

Crear la imagen Docker con Corosync

Lo primero que haremos es generar en el volumen para almacenar datos persistentes del contenedor, una carpeta necesaria para generar el contenedor:

Si las queréis hacer por comando:

mkdir -p /volume2/Docker/corosync-proxmox

Una vez creado, usaremos Portainer para crear el contenedor. Generaremos un Stack nuevo. Accedemos a la configuración Stacks -> Add stack:

Le ponemos por ejemplo de nombre corosync-qnetd o corosync-qdevice:

Usaremos un fichero YAML con el siguiente contenido:

version: "3.8"services: qnetd: image: debian:12-slim
 container_name: corosync-qnetd restart: unless-stopped
 network_mode: host volumes:
 - /volume2/Docker/corosync-proxmox:/var/lib/corosync-qnetd
 command: > bash -c " apt update &&
 apt install -y corosync-qnetd && corosync-qnetd -f "

Pulsamos Deploy the Stack:

Al terminar se generará el contenedor:

Al usar "--privileged" y "--net=host", el contenedor tiene visibilidad total de la red y acceso al kernel del NAS. Nos aseguraremos de que el archivo corosync.conf tenga los permisos correctos (600 o 644) y que solo el usuario root del NAS pueda editar esa carpeta /share/Docker/corosync/.

Con esto ya tendríamos el contenedor preparado y escuchando.

Configuración y verificación del Clúster Proxmox

Realizamos una verificación de conectividad en uno de los nodos del cluster proxmox:

nc -zv 192.168.2.50 5403

Ahora necesitamos terminar los trabajos en el clúster. Forzamos la configuración del dispositivo qdevice:

pvecm qdevice setup 192.168.2.50

 

Verificación del Quorum en Clúster Proxmox

En cualquier nodo Proxmox:

pvecm status

Debería mostrarnos:

QDevice: Status: OK Votes: 1

Y el total de votos:

Nodes: 2Expected votes: 4Total votes: 4Quorum: 3

Ese “Nodes: 3” significa:

• 2 nodos reales
• 1 qdevice

Pero los votos totales son 4 por diseño interno.

Quorum en Clúster Proxmox

En entornos basados en Proxmox VE, el diseño del quorum no es una preferencia operativa, sino una restricción matemática inherente a los sistemas distribuidos.

La comparación final es clara:

Cluster de 3 nodos (sin QDevice)

• Total votos: 3
• Quorum: 2
• Puede tolerar la caída de 1 nodo
• Si caen 2 nodos, pierde el quorum
  • Ventaja: simplicidad y arquitectura limpia.
  • Limitación: no puede sobrevivir a la pérdida de mayoría.

Cluster de 2 nodos + QDevice

• Nodos físicos: 2
• QDevice externo: 1
• Expected votes: 4
• Quorum: 3
• Puede tolerar la caída de 1 nodo
• Evita split-brain mediante árbitro externo
  • Ventaja: solución correcta para clusters pequeños de dos nodos.
  • Limitación: tampoco puede sobrevivir a la pérdida simultánea de dos componentes.

En ambos modelos, la regla es inmutable:

"Se necesita mayoría absoluta para mantener consistencia."

Ni añadir un QDevice a un cluster de 3 nodos permite que un único nodo sobreviva a la caída de los otros dos, ni existe una configuración soportada que rompa esta lógica sin comprometer la integridad del sistema.

Si el requisito operativo es tolerar la caída de dos nodos, la única arquitectura válida es:

• 5 nodos (quorum = 3), o
• Rediseñar el modelo hacia nodos independientes sin cluster.

El quorum no está diseñado para maximizar disponibilidad a cualquier costo, sino para garantizar coherencia y evitar corrupción de datos.

En sistemas de virtualización y alta disponibilidad, consistencia siempre tiene prioridad sobre continuidad forzada.

Esa es la base sobre la que opera Corosync, y por extensión, cualquier cluster serio en producción.

Fin del Artículo. ¡Cuéntanos algo en los Comentarios!